Qex versus the Video game

In basic approach, Qex is not much different from your favourite RPG computer game. It’s been reasonably asked of me “Well why re-invent the wheel? Why make a program to do what essentially any game with a level editor can do?” And to answer that, one must become acquainted with the essential rules that Qex follows (which games do not). I’ll call these maxims. They are rules which a game should follow if a GM is to use it to run his campaign.

Qex is not exactly a game, of course. It’s a Virtual Tabletop Application. It’s meant to aid in playing another game. So it requires more flexibility than basic games do.

Here are the three design maxims.

Maxim #1: The Interface Needs to Work.

All the best games have easy interfaces. A fellow coder once surmised “A bad game with a good interface can still be a lot of fun to play”. But what is a good interface? I’ll point at Starcraft. Starcraft’s interface is complex to a novice. Different units produce different items. Some items unlock other items. Building must be performed in a certain order. But all those buttons follow a sequence (generally from top to bottom). And with few exceptions there are logical keyboard shortcuts for everything (“M” for move, “P” for patrol). A good Starcraft player will tell you that half the game is mastering those shortcuts. So Starcraft takes a fairly complex building system and creates a fast, logical system out of it.

And a bad interface? We’ve all played that game that was hard to work in. I’ll look at Dream of Mirror Online for an example. In this game, they redefined the user interface instead of using default Windows controls (of course, most games do that). The problem? 1) Scrolling is slow. 2) Text selection is counter-intuitive. 3) Multinational users can’t type accents.

Let’s break that down closely.

(1) Scrolling is slow. You can’t use the mousewheel to scroll or PageDn / PageUp on the keyboard. The game designers probably had no use for it, so they never added it. If someone said something “10 pages ago” it’s virtually lost. Also, the ability to copy text into notepad would have been great for preserving complex instructions.

(2) You can’t select a line of text and delete it. It can take 10 seconds to delete 50 characters of text. Let’s say you started to type “Let’s escape through that door” and realized that there’s a giant monster behind the door. You have to delete that message now. You can be caught in an epic battle, with your comrades dying around you and can’t do anything for several seconds while you patiently delete your message.

(3) Lack of accents makes hastily typed queries harder to read. After all, in French, “tue” (kill) and “tué” (killed) are very different things. Incidentally, the game failed in Europe. Can anyone guess why?

Summary: A complex application need not re-invent basic controls.

Starcraft has a relatively complex number of choices in just 9 buttons.

In DOMO, this should probably be a Windows RichEdit control with a black background. The cost: Loss of translucency (although Vista and 7 could do it) and loss of portability (Well they only support Windows anyway). The gain: (1) Ease, speed of typing. (2) full Windows keyboard support, including accents and Chinese characters (3) copy / paste (4) support for future Windows-compatible technologies that haven't been invented yet (eg mouse-wheel)

Maxim #2: The Application Needs to Work

Ever play your game and get to some difficult point only to have it crash? Lost your game progress? Qex operates on the principle that you should always be able to save.

If you say you support Windows, your program should probably work on “most” versions of Windows. If you can support XP and 7 but not Vista, you are breaking user expectations.

Summary: Never crash & close out. A good number of crashes is zero.

Maxim #3: User Placement is Sovereign

A user needs to be able to place a character / sprite / entity anywhere on the map. In the course of adventuring, Bob the Wizard may have teleported himself into a solid granite wall. There needs to be a way for the GM to put his miniature in that hex if required.

This was a major failing in the otherwise great engine for Dungeon Siege. All those beautiful landscapes and you just couldn’t get your character to navigate a 45° incline. Position "A" is inaccessible to the GM (unless he redesigns the map) because the stones are too steep for the character to climb. Furthermore, the GM has no ability to place a monster in that position unless he stops the game and again, redesigns the map - the camera is always attached to an existing object.

While playing and struggling to translate concepts to a computer screen, the last thing a GM wants is to have to fight the system to start a fire underwater, or make an Orc strong enough to carry a castle (In Qex, I once gave an Orc one million strength).

Just let the GM do it... if it’s not what he wanted he’ll fix it himself.

Summary: An application should help the GM, not nanny him.

In conclusion...

Qex runs in a window instead of full screen (users are going to want to tab out). And yes, it allows you to place an object into a “void” area. It doesn’t have built-in video chat because Skype already invented that wheel (there are plans for text chat by version 1.0). All these things and most Qex features that differ from video games are to satisfy these design maxims.